I guess I can fix the first one by mapping the dylibs to their parent directories, but I'm not sure why that was a test in the first place (it doesn't test the formula's functionality or really mean anything in terms of it working). Thoughts on removing that particular part of the test (and replacing it with something else)?

Edit: Same goes for vim and macvim - is there a reason we're testing for dylibs in their test blocks instead of feeding them a basic command sequence to see if they actually execute?

The second failure is a bit strange, since there definitely is a /usr/local/Cellar/libgcrypt/1.7.5/lib/libgcrypt.20.dylib in .libs/random:

bash-4.4$ otool -L .libs/random 
.libs/random:
	/usr/local/Cellar/libgcrypt/1.7.5/lib/libgcrypt.20.dylib (compatibility version 22.0.0, current version 22.5.0)
	/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (compatibility version 21.0.0, current version 21.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

I doubt it's a bug in ruby-macho, but I guess I have to go check that now 😢

Attached IRB confirms this:

irb(#<MachO::MachOFile:0x007ff76a1c3d88>):004:0> @filename
=> #<Pathname:/private/tmp/libgcrypt-20161220-36566-s5knjf/libgcrypt-1.7.5/tests/.libs/random>
irb(#<MachO::MachOFile:0x007ff76a1c3d88>):005:0> linked_dylibs
=> ["/usr/local/Cellar/libgcrypt/1.7.5/lib/libgcrypt.20.dylib", "/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib", "/usr/lib/libSystem.B.dylib"]

Never mind, I'm an idiot. Ruby-macho doesn't like Pathnames...

Nice. I like the approach.

I've been away from my OS X box, but I'll try to fill this PR in soon.

404ing on libsvm, sent the maintainers an email.

pypy3 is complaining about the "alpha" in the URL, but I assume that's fine since that's the way it was.

amap is complaining about assert...include?, but assert_match doesn't do what we need here.

Opened #8706 to fix libsvm.

pypy3 is complaining about the "alpha" in the URL, but I assume that's fine since that's the way it was.

yep. it would be nice to explicitly white list it so this stop happening.

amap is complaining about assert...include?, but assert_match doesn't do what we need here.

that's a brew bug.

yep. it would be nice to explicitly white list it so this stop happening.

Do we already have a formula whitelist for audit, or is it something we need to add?

that's a brew bug.

Yep, I figured 😄

There are a variety of whitelists in diagnostic.rb

There are a variety of whitelists in diagnostic.rb

Those don't affect audit, do they? The problem causer is this in audit.rb:

if line =~ /assert [^!]+\.include?/
  problem "Use `assert_match` instead of `assert ...include?`"
end

I can either tweak that regexp to be a little more discerning, or split the test in amap into two lines to trick audit.

I was talking about pypy3

Oops, misread. Sorry!

Pinging @zmwangx since you added aec4473 to fix Vim's otool usage - any chance of a similar fix for MacVim? Just wondering if I should expend the effort to fixing this linkage test instead of tossing it out in favor of something more practical.

any chance of a similar fix for MacVim?

I don't know if there's chance for a fix, but even if there is it probably won't be similar. Vim doesn't have a non-interactive mode, and for MacVim, that means however you call it, the GUI is launched, and whatever info we might need is displayed in the GUI. Anyway, not really a day to day vim user, so take my opinions with a grain of salt.

however you call it, the GUI is launched

Oh wait, actually, mvim --version might work. It contains

Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX  -F/usr/local/opt/python/Frameworks -I/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/include/python2.7 -fno-strict-aliasing -fno-common -dynamic -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1

so I guess you can tell from -I/usr/local/Cellar/python/2.7.13/ whether it is peeking into the wrong version of Python.

@BrewTestBot test this please

Sierra-only failure:

haskell-stack: This formula either does not compile or function as expected on macOS
versions newer than El Capitan due to an upstream incompatibility.
Error: An unsatisfied requirement failed this build.

That's the MMOSR. IIRC it won't be resolved until at least GHC 8.0.2 is released: commercialhaskell/stack#2577.

This isn't tremendously high priority, so I'm fine with waiting until 8.0.2.

That is normal. The point of the rpath manipulations in the haskell-stack formula is to allow the El Capitan bottle to be used on Sierra. I suggest you remove the revision bump from the Haskell-stack formula and merge this PR without pulling any bottles for any of the formulae. It doesn't need to go through CI again.

Alrighty. Works for me 😄

I'm going to do the macvim otool removal in another PR, to avoid chewing through these again.

🎉